home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group97a.txt
/
000068_icon-group-sender _Tue Mar 4 14:33:17 1997.msg
< prev
next >
Wrap
Internet Message Format
|
2000-09-20
|
5KB
Received: by cheltenham.cs.arizona.edu; Tue, 4 Mar 1997 14:44:43 MST
Date: Tue, 4 Mar 1997 14:33:17 -0600
Message-Id: <199703042033.OAA32615@ns1.cmpu.net>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: gep2@computek.net
Subject: Re: Icon and two-dimensional matching
To: icon-group@cs.arizona.edu
X-Mailer: SPRY Mail Version: 04.00.06.17
Errors-To: icon-group-errors@cs.arizona.edu
Status: RO
Content-Length: 4250
>>SNOBOL4 absolutely DOES support substrings as a pseudovariable, as long as the
substring in question is the portion of the subject string that you're matching.
This, in fact, is the basis for ALL pattern matching in SNOBOL4!
>No, at least not in the sense that I'm speaking about. Yes, it's possible
to replace a substring (assign to it) in the middle of a string, thus making
a string replacement statement a form of assignment.
Right... in essence, you're using a "pseudovariable", replacing a specified
substring in a subject string, in an assignment statement. This is one very
reasonable definition for a pseudovariable (okay, I agree that the syntax is a
little different than would be done in other languages, but anyhow that's
typical for S-BOL in a lot of ways!)
>But that alone
does not make a substring, either identified through pattern matching
or using SUBSTR into a pseudovariable; one can't form the NAME of any
sort of expression including a substring -- that's reserved to variables --
It's pretty trivial to evaluate the string value of the substring and put that
into a variable.
>to pass it as an argument IN SITU to a called function for example.
Okay, but it's certainly easy enough to pass the VALUE to a called function in
S-BOL (okay, not in SIL SNOBOL4):
func(p1,(str ? pattern),p3)
Admittedly that wouldn't allow modifying the substring in place from within the
function.
>Passing cross-sections of arrays to a routine is a bit more interesting in
Algol 68 than in PL/I;
I *do* think it curious that Algol (and particularly Burroughs Extended Algol,
which was very highly regarded by those friends who used it back when I was at
the University of Illinois) seems to have really disappeared as a language for
current development. At the time, I used PL/1 quite heavily, and liked the
language a lot. I think I would enjoy having a good PL/1 compiler for my PC,
although I'm not really certain right at this instant what specific things I
would do with it if I had it... perhaps mostly for nostalgia value, but I think
I'd find stuff to do with it.
>>>I'm interested in generalized macro processing, where the macro
>processing becomes a method - a dynamic method - of program
>language development, and that plays just as much a part in program
>development as algorithm design, module design and data structure
>design. One specifies the TRANSLATION of algorithms, data
>specifications, ... into code. Previous passes over the text or previous
>work in the same pass where rescanning is allowed, besides perhaps
>transforming the text, may decorate it with tokens (roughtly, a structure
>containing a source string and other information), or with trees or with
>other structures and with other information. Then one has to recognize
>patterns among the tag-along information and source text, and to
>process it both by generating new information and transforming the
>structures and data that exist.
>>One of the shortcomings of Icon (compared with S-BOL), IMO, is that Icon
>supports neither EVAL() nor CODE(). Admittedly these are features that one
>doesn't use often in most S-BOL programs, but when you -do- need them, they
are absolutely indispensable!
>Right !
>>In the case in question, you could use the full features of S-BOL to modify
the
>program itself at source level, and to replace almost any desired part of it
>with an "enhanced" version during program execution... even in the middle of a
>statement!
>Right, but I'm considering general macro processing, and trying to avoid fixing
it to any one language or compiler, even though for what I'm doing, there
has to be a base language for the macro stuff.
Obviously. I think that a language like S-BOL would be ideal for macro
processing, due to the intrinsic features in the language. Part of what makes
it *especially* interesting is the ability to have the S-BOL macro processor
PERMANENTLY augment its own features by adding code and using SAVE() to update
its own code file with new features... allowing for a kind of persistence which
is very difficult, I think, to do with other languages (even Icon) as a base.
Gordon Peterson
http://www.computek.net/public/gep2/